Many enterprises use software to perform various tasks in furtherance of the business of the enterprise. For example, an airline may use such software to receive reservation requests from customers and travel agents. In addition, the airline may use business software to track planes, schedule flight crews, arrange for in-flight meals, order fuel and monitor parts inventory.
Traditionally, software employed by an enterprise is customized to one degree or another. For example, software (e.g., an airline reservation system) may be custom-built from the ground up. Alternatively, the software may begin as an off-the-shelf product, and then undergo some level of modification. In some cases, software that was custom-built has undergone modifications and updates to bring it in line with current requirements.
Customized software is associated with at least two problems. First, customization is labor-intensive, and thus any customization of software is expensive. Second, customizations are often poorly documented, thus making it difficult to maintain the software, or make further customizations to it. Often, attempts to modify customized software produce unintended results, which is partly due to the fact that there is no structured way to connect the implementation of the software with the original goals that the software was intended to accomplish.
Business software, and the hardware needed to implement it, of older existing business software systems are commonly referred to as “legacy” systems. Legacy systems are typically examples of custom software that is difficult to modify. Even legacy systems that were not custom-built share many of the problems of custom software, because they may be poorly documented. A legacy system is an existing system within a company that continues to be used despite being out-of-date, incompatible with current systems, or otherwise undesirable. Generally, legacy systems tend to be difficult and expensive to modify and unnecessarily large. Thus, legacy systems typically continue to be used despite such shortcomings because the cost of replacing or redesigning the system may be prohibitive. As a result, the company is forced to trade-off a certain level of competitiveness relative to its more modern competitors because of the expense of replacing a legacy system.
Legacy systems are often difficult and expensive to update. In many applications, the software for such systems is written in old computer languages and may have been custom-made for the company. As a result, any attempts to further update the software may require the company to obtain assistance from the original vendor, who may have institutional knowledge of the company's software. However, in some cases the original vendor may be very expensive, unavailable or even out of business. Alternatively, the company may have another vendor update the software, which will invariably require in-depth analysis of the software before a programmer can become familiar enough with the software to implement an update. The additional effort required to perform an update to a legacy system also increases the monetary costs associated with the update. In addition, the software may be proprietary, so the company is forced to deal with a vendor who effectively has a monopoly over the software and who can therefore charge higher prices.
Legacy systems, as well as newer conventional business software systems, often lack adequate documentation to enable a programmer to understand the system and to determine which other systems, if any, might be affected by a change. For example, software in one part of a system may have been written specifically to run on a certain type of computer. Without sufficient documentation, a programmer intending to run the software on a different type of computer may have great difficulty determining which parts of the software code were computer-specific. Therefore, the added time required for the programmer to determine which parts of the software need to be changed adds to the costs involved with the change. The programmer may also be unaware that a change to the software in one system may have an effect on another system. For example, another system that is either within or outside the company may communicate with the software that is running on the original computer by using a computer-specific software protocol. By changing the computer and its associated software, the other system may no longer be able to communicate with the software. Thus, the programmer may not know that a problem exists until the change is implemented and the systems can no longer communicate, which again adversely affects the costs of the software change.
Current attempts to create a method for upgrading and replacing legacy systems are still too cumbersome and expensive. For example, a conventional process for upgrading an enterprise's system typically customizes the upgrade process from the ground up. As a result, an upgrade is a time- and money-consuming process that requires a large upgrade budget that may be out of reach for many companies. Other systems may not be customizable at all, or at most only a minor amount of customization may occur, thereby locking a company into using a system that may not be a perfect match for its business.
In addition to the typical shortcomings of legacy systems, there also shortcomings in the conventional methods for automating business processes in business software. Fundamentally, any software application—such as an application that is used as a business software system—is a set of instructions that can be followed by a computer to perform one or more tasks. Traditionally, a software application was designed by identifying the task(s) to be performed and writing instructions to perform those tasks in a programming language, such as C or C++. The disadvantage to this traditional approach is that it requires the software developer to model the development process in terms of the low-level actions that a computer can be instructed to perform, rather than in terms of the contemplated use of the software by actual business users. For example, if the software to be developed is an organization-wide scheduling system for a company, the traditional approach to software development may require the developer to model the problem in terms of how calendars are represented as data structures and manipulated arithmetically, how users are uniquely identified within the system, etc. This type of model for the software is at a much “lower-level” than the business problem that the software is intended to solve.
Software development tools, such as the RATIONAL ROSE visual modeling tool from Rational Software Corporation, seek to improve on the traditional software development process by allowing the function of the software to be modeled at a relatively higher level of abstraction. With RATIONAL ROSE, instead of modeling the requirements for software in terms of the basic actions to be performed by a computer, a software developer can abstract the software under development in terms of “use cases” and object models. A “use case” is an instance of the use of the software by an actor. For example, in the scheduling system mentioned above, a use case might be a calendar owner's scheduling of a personal appointment on his or her calendar. Having identified one or more such use cases, the software developer can build the software by separately modeling and then coding each of the use cases.
Use cases are a useful abstraction because they allow the software developer to create software with a view toward specific situations that the software will be expected to handle. However, use cases still have the drawback of being, in many situations, at a much lower level of abstraction than the requirements for which the software is designed. Software is generally envisioned to meet the requirements of a business model, and a business model is usually conceived as a high-level plan to implement a business process, rather than as a collection of specific examples of how the software will be used. For example, the management of a company (which, in many cases, is composed of a group of non-programmers) may envision a scheduling system that meets certain requirements and solves certain scheduling problems. However, the management's vision for such a system is not likely to be at a level of detail that includes all of the exemplary uses of the system (e.g., scheduling a personal appointment, scheduling a company-wide event, canceling an appointment, deleting from the system a user who has left the company, etc.).
In addition, management's vision will most likely not indicate where all of the interrelationships between such a system and any other system in the company may lie. Also, documenting each of the systems and processes in a company that are to be implemented in software code and the systems' and processes' interrelationships can be an extremely time consuming process that is prone to error.
Accordingly, what is needed is a technique for creating a solution to business software that allows the software to be designed based on the business vision that the software is intended to implement, takes advantage of reusable software designs and components, and allows the software (as well as any customizations and future changes) to be documented. Such a technique would allow software to be developed at a lower cost, would allow for a close correspondence between the software and the business vision that the software is designed to implement, and would also simply future upgrades or modifications to the software by systematically documenting the relationship between the software itself, the software's design, and the business model that the software is designed to implement. No such system has been realized in the prior art.